The problems and solutions addressed by the invention are described herein in terms of the Internet and the TCP/IP protocols that form the basis of Internet communications. However, the invention can apply to other communication protocols as well, depending on the specifics of the protocols.
Internet Network Address Translation is used for several reasons. The main reason is to economize on the use of public addresses. The Internet Protocol (IP) address of a Network Address Translator (NAT) is generally a public address. That is, the NAT IP address is known to the outside world, while all of the servers or clients behind the NAT are private addresses, unknown to the outside world. In such a case, the outside world communicates with the NAT and the NAT controls the communications with the appropriate servers and clients behind it. This means that the IP addresses of devices behind the NAT only have to be unique within that family, but can be duplicative of other IP addresses in the rest of the world. NATs involve only the translation of IP addresses. There is a further type of translation known as Network Address Port Translation (NAPT) in which both IP addresses and port numbers are translated. The standards for Network Address Translation (NAT) and Network Address Port Translation (NAPT) are set forth in the Internet Engineering Task Force (IETF) RFC 3022, entitled “Traditional IP Network Address Translation”.
The original Internet was not designed with security as a primary factor. In fact, the Internet was purposely made relatively open as an aid to scientific and educational communication. However, the advent of the Web and its commercial uses has increased the need for secure Internet communications. The Internet Security Protocol, commonly known as IPsec, was defined to address these issues. For example, IPsec provides for the authentication of network devices and/or for the encryption of transmitted data. An IPsec communication between source and destination addresses is administered in accordance with a security association (SA), which is one or more rules that define the IPsec processing that is applied to the communication. IPsec is defined in RFC 2401 and other RFCs. Whether a packet is denied, permitted without IPsec processing or permitted with IPsec processing is determined by matching the attributes of a packet with the security rules in a security policy database (SPD). To make this determination the known art searches both static and dynamic rules in the order of most specific to least specific attributes for both outgoing and incoming packets. A set of static rules is essentially a security policy. Static rules are predefined and generally do not change very often. Dynamic rules are rules that are negotiated between nodes during IKE (Internet Key Exchange) processing and are added to the security policy database in a dynamic fashion as needed. U.S. Pat. No. 6,347,376 to International Business Machines describes a preferred method of searching the static and dynamic rules of an SPD. This patent is incorporated herein by reference in its entirety.
There are inherent incompatibilities between network address or port translation and IPsec processing. These incompatibilities are a barrier to deployment of IPsec. RFC 3715 recognizes and discusses some of these incompatibilities, but offers no general solutions. For example, Section 4.1 of RFC 3715 refers to a limited solution proposed in RFC 3456, “Dynamic Host Configuration Protocol (DHCPv4, Configuration of IPsec Tunnel Mode”), but states that a more general solution is needed. In addition, Section 5 of RFC 3948 entitled “UDP Encapsulation of IPsec ESP Packets” from the IPsec working group of IETF also addresses some of the incompatibility problems. Particularly, Section 5.2 of the RFC describes briefly a problem in determining what IPsec security associations to use on connections to clients served by a NAT. This Section also describes another problem in allowing a clear text connection to a client behind a NAPT when the NAPT also handles IPsec traffic.
The present invention is directed to the problem of avoiding duplicate sources when clients are served by a NAPT. No solutions are provided for this problem by any of the related IETF RFC documents. For purposes of this specification, duplicate sources are defined as packets having the same source address (e.g., an IP address of a NAPT assigned to an IPsec encapsulated original packet), the same transport protocol and the same original source port number (i.e., a port number in the transport header of the IPsec encapsulated packet).
Duplicate sources result in duplicate connections that breech network integrity. For example, packets can be sent to the wrong destination.
RFC 3947 entitled “Negotiation of NAT-Traversal in the IKE” describes what is needed in the IKE (Internet Key Exchange) phases 1 and 2 for the NAT traversal support. This includes detecting if both ends in a packet communication support NAT traversal, and detecting if there are one or more NATs along the path from host to host. It also covers how to negotiate the use of User Datagram Protocol (UDP) encapsulated IPsec packets in the IKE Quick Mode and describes how to transmit an original source IP address to the other end if needed”. The UDP is defined in RFC 768. RFC 3948, “UDP Encapsulation of IPsec ESP Packets”, defines methods to encapsulate and decapsulate ESP (Encapsulating Security Payload) packets inside of UDP packets for the purpose of traversing NATs. ESP is defined in RFC 2406. ESP is designed to provide a mix of security services in IPv4 and IPv6.